Increasing advances in computer technology (e.g., microprocessor speed, memory capacity, data transfer bandwidth, software functionality, and the like) have generally contributed to increased computer application in various industries. Ever more powerful server systems, which are often configured as an array of servers, are often provided to service requests originating from external sources such as the World Wide Web, for example. As local Intranet systems have become more sophisticated thereby requiring servicing of larger network loads and related applications, internal system demands have grown accordingly as well. As such, much business data is stored in data stores, under a management system.
Moreover, the amount of available electronic data is continuously growing, and it has become ever increasingly important to store such data in data stores in a manageable manner, which facilitates user friendly, and quick data searches and retrieval. In general, a typical data store can be referred to as an organized collection of information with data structured such that a computer program, for example, can quickly search and select desired pieces of data.
Data within a data store can be organized via one or more tables, wherein respective tables comprise a set of records, and a record can comprise a set of fields. Records are commonly indexed as rows within a table and the record fields are commonly indexed as columns such that a row/column pair of indices can reference a particular datum within a table. Typically, such data stores can be viewed as organized collection of related information stored as “records” having “fields” of information therein. As an example, a data store of finances may have a record for financial transactions such as accounts receivables, amount owed, customer information and the like. Between the actual physical data store itself (i.e., the data actually stored on a storage device) and the users of the system, the management or operating system can typically provide a software cushion or layer. As such, the data store can shield users from concerns about the underlying hardware-level details. Generally, all requests from users for access to the data are processed by the system manager. For example, information can be added or removed from data files, information retrieved from or updated in such files, and the like, all without user knowledge of underlying system implementation.
At the same time, conventional data stores and operating systems have typically relied on multiple incompatible storage for data, including; the registry, event log messages, contact information, and e-mail, or simply have used multiple flat files for data such as images and audio. For example, in conventional data stores stored contents are in general treated as separate entities, even though they are interrelated at some level. Accordingly, when a large number of items exist, it can become important to have a flexible and efficient mechanism to search for particular items based on their properties and content. For example, it can be desirable for knowledge workers to be able to search for contents independent of format—regardless of what type of a file a particular content is and what application created that.
Given a new file system that operates based on relational objects, new challenges can arise. For example, there can be new ways that a virus can store itself in such file system. Typically, conventional virus checking are limited to performing virus checks for files that are stored generally in the same computers upon which anti virus programs are executing. Accordingly, while specific entities, including end users and web sites, can to an extent be capable of performing virus checking on files stored locally on their computers, oftentimes those entities are not capable of determining the viral risks associated with files under the control of other entities, wherein malicious codes can employ encoded strings being deposited in the store that will get decoded in the client space and propagate through email. Thus, for a conventional file system, a virus can be resident in one or more streams of the file, and nonetheless such is simply one file.
On the other hand, in relational Item Stores, content can be persisted in an item, wherein an item can include a plurality of properties, with each property associated with various other items. Thus, saving to the Item Store and reading back from the store can include results that can be aggregated over many properties of many items. This can create a different paradigm; such as creating an update path or read path with many properties. Viruses can employ such arrangement for hiding themselves in “piece meals”, for example, a virus can store an encrypted body ‘X’ in the property of an object, and propagate by querying the store and decoding the encrypted property on the client, such as a metadata for an image that can appear innocent to an anti virus programs.
By distributing the body of the virus over multiple properties and multiple items the Item Store can become a virus store. Put differently, a virus can be stored in pieces and may write itself into the properties of multiple items, with a naïve query aggregating such pieces and leading to execution of the virus. Accordingly, a conventional filter model to intervene in the update or read path is in general no longer appropriate for such relational Item Store arrangements.
Therefore, there is a need to overcome the aforementioned deficiencies associated with conventional systems and methodologies related to Item Store operations.